Controlling Parameters in Audio Software
Most analogue audio equipment is built following the “one knob per job” idiom. This means that each adjustable setting option that influences the sound of the device is controllable using one dedicated hardware control. Hence this hardware control can be designed to enable optimal controllability regarding the “functioning” of the parameter, for instance:
The level of a channel of a mixing console is controlled by a linear fader, as its position is easily readable, and multiple adjacent channel's levels are controllable simultaneously, as the user can adjust multiple faders' positions using one finger per fader.
The cut-off frequency of an analogue synthesizer's filter is controlled by a dominantly sized potentiometer, as it is one of the most frequently adjusted and most influential parameter to the synthesizer's sound.
The octave selector of an analogue synthesizer's oscillator is built as a detented “chicken head” knob with as many discrete positions as the oscillator provides octave settings, as this knob type's setting is clearly readable and it is highly improbable to inadvertently misadjust the knob.
This variety of control elements and the resulting level of controllability is what often gives analogue audio equipment its distinctive feel and satisfies its user's hedonic desires. However, when simulating analogue audio equipment in software, those dedicated hardware controls often turn into mere parameters, only represented by an illustration displayed on the computer screen, resulting in a loss of affective qualities and reduced level of controllability.
In most common audio software there are two ways to manipulate a parameter's value: It can be adjusted either directly, using the computer mouse or a touch screen to manipulate the parameter's on-screen visual representation, or remotely by using controls on an additional hardware controller.
In most cases, such an additional hardware controller is generic and therefore configurable to work with most common audio software by utilizing standardized communication protocols (e.g. MIDI), whereby the user is usually free to assign the hardware's controls to the parameters offered by the software. This means that one control on the hardware may represent different software parameters, depending on the current mapping.
The following generic control types, usually to be found on standard audio software controller hardware are generally provisioned for controlling software parameters:
Rotary potentiometers with a left and right limit, occasionally with an additional zero detent
Rotary endless encoders
Stepped rotary endless encoders
Linear potentiometers
The generic hardware controllers are further also mostly agnostic of their currently assigned parameter's functioning. This often results in that users encounter “disconnect” situations, where a hardware control is mapped to a software parameter in such a way that the hardware control does not at all represent the controlled parameter's functioning. Situations like this are for instance:
A parameter with a limited value range is mapped to an endless rotary encoder.
A parameter with a continuous value range is mapped to a stepped encoder.
A parameter with a number of discrete values is mapped to a non-stepped encoder.
In all these cases, the controllability of the parameter through the user is reduced in comparison to the appropriate “parameter functioning-control type” pairing. The parameter value might not be adjustable as precisely or quickly, and the generic control might further not emanate the impact of its associated parameter towards the sound.
In another special case of using common audio software, the controls on current hardware controllers may not only be mapped to adjust an audio signal processor's parameter value, but also for other control tasks such as list selection, for instance to select a parameter preset for a virtual instrument, or the next song to play in a DJ software. Most current controllers provide stepped encoders for this use case, as the user is provided with a distinct tactile feedback for each incremental change in the selection.
However, navigating long lists can become very cumbersome and time-consuming using this method, as the number of steps on most rotary encoders is small compared to the number of list entries commonly found in these use cases. Navigating for instance through a list of only 1000 songs using a 24-step encoder, the user may have to turn the encoder for multiple full revolutions until the desired list entry is found. Some software tries to counteract against this problem by introducing behaviours similar to the mouse acceleration functionality, namely that the selection offset per encoder increment is amplified depending on the turning speed of the encoder. This method, however, leads to a disconnect between the haptic feedback provided by the encoder increments and the selection progress.
On current touch screen computers, the problem of navigating long lists that display only a small subset of their items is mainly solved by modelling the list's motional behaviour by using an inertia simulation. A user can introduce movement to the list by swiping the list's displayed entries into the desired direction. When the to-selected entry becomes visible, the user can stop the list's movement by tapping down a finger onto the list's visual on-screen representation, then appoint the to-selected list entry by tapping into its corresponding screen real estate.